Making modifications or enhancements to software running in a live computer system requires careful testing and deployment, especially if the system is a large transaction processing system such as VisaNet™, which processes over one hundred million financial transactions (e.g., credit card transactions) per day. Typically, a set of software modification projects are initially tested in a test environment which emulates the actual transaction processing system.
The test environment is typically simulated on a mainframe computer system using program instructions and parameters encoded in JCL (Job Control Language). In JCL, a program unit for executing a particular task is referred to as a ‘job’. A job may reference and call various procedures (procs) which perform specific operations and the procs call executable modules or programs. A number of jobs are generally executed in a sequence to test a scenario in the test environment.
As shown in FIG. 1, one known system 10 in the prior art employs a JCL offline test tool (JOTT) 12 which generates an output JCL file 14 including one or more jobs for use in a test environment. The program JOTT 12 is discussed more fully in U.S. Pat. No. 6,430,708, issued on Aug. 6, 2002, which is incorporated herein by reference. The output JCL file 14 is generated based on an input source JCL file 16 and an environment code file (‘script’) 18. The environment script 18 is used to configure the environment in which the output JCL 14 operates. The environment script 18 includes lines of code that specify variables for which values are not yet set, and overrides which change the names of certain variables. A portion of an exemplary source JCL is shown in FIG. 8. The portion of the source JCL file shown includes, among other items, a job reference (first line), associated variables 803, a procedure library reference 804, and a procedure call 806 including associated variables 807.
In addition to generating the output JCL file 14, JOTT 12 also generates support files 20 such as an environment test parameters file 22 that specifies operating parameters of the environment, a FLOW file 24 which lists jobs generated in an order in which they should be submitted for execution in the environment, a JCLLIST file 26 which lists environment details such as various overrides and jobname overlays for changing job names, a JCLOVER file 28 with a collection of most of the specific override instructions pertaining to the JCL 14, a NOTES file 30 for listing text notes such as error messages, a VALIDATE file 32 listing a date of validation of the JCL 14, and a HOTLIST file 34 listing a collection of specific override instructions such as dataset name overrides.
In such prior art systems, the numerous support files 22-34 do not provide any clear definition of where global changes have been made in generating the output JCLs 14 based on a specific environment script file 18. That is, a library of different source JCLs 16 may be the basis of a library of output JCLs 14 adapted to a specific environment, and global changes, such as overrides, may be applied to entire source library 16 to generate a library of output JCLs 14. Although the support files 20-34 may indicate specific overrides, none of the support files 20-34 in the prior art provide a clear indication of global overrides spanning the library of source JCLs 14 in a common JCL library for an environment.
It would be desirable for a JCL generating module to indicate global aspects of JCLs generated and operating in a common environment.
In addition, such prior art systems including JOTT 12 utilize expensive and complex utilities, which hinder effective generation of output JCLs 14 in test environments. For example, in the prior art systems 10 using JOTT 12, the generation of the output JCL 14 is performed inefficiently, as follows.
In the process of generating output JCL file 14, the system 10 operates according to the method shown in FIG. 2, in which JOTT 12 receives the input files 16,18 in step 36, opens the source JCL file 16 in step 38, and determines in step 40 an initial job listed in the source JCL file 16 to be a current job to process. Each source JCL file 16 lists one or more procs to be called and performed on a line-by-line basis.
The prior art method (of FIG. 2) opens a first proc called by the current job in the source JCL file in step 42, with the first proc as the current proc to process. In “opening” the proc, the prior art system reads and determines the source proc, such as the library and path for accessing the proc. The step of opening a procedure or proc involves opening a new variable for the output JCL file 14 which is to be named and loaded with data, such as a proc name to be used by the output JCL 14 in the environment. JOTT 12 then applies changes to the current proc in the current job in step 44 based on the input files, such as the environment script file 18, by filling in the opened variable. The method then determines in step 46 if all of the procs in the current job have been processed. If not, the method then finds the next unprocessed proc in the current job in step 48 to process, and loops back to perform steps 44-46 to iteratively process every single proc until all procs in the current job have been processed in step 46.
The method then proceeds to step 50 to close the processed procs in the current job, for example, by saving the record of the variables or modified procs being generated in the output JCL 14. In step 52 it is determined if all of the jobs in the source JCL 16 file have been processed. If not, the method finds a next job in the source JCL 16 in step 54 to be the next current job to process, and loops back to perform steps 42-52 to iteratively process every single job and every single proc, until all procs in all of the jobs of the source JCL 16 have been processed in step 46.
In the above described method, procs processed in an earlier job may be identical to procs processed in a later job, and the same procs are reopened every time they are encountered in a current job. New variables and new values are repeatedly generated for each proc until the final output JCL is generated in step 56, regardless of earlier-performed operations.
Each time a proc is opened, there is an incremental processing time for the opening process. Although JOTT 12 and such test environments are operating on relatively fast computer systems, over any length of time, the incremental processing time involved in each opening process accumulates to become noticeable delays in processing which slows the generation of the output JCL file 14. For projects implementing changes in hundreds or thousands of JCLs in multiple environments, such repeated opening and closing of procs result in significant delays in testing and implementing new software in test environments and, ultimately, delays full implementation in real-world environments, for example, in transaction processing systems.
It would therefore be desirable to avoid such delays, and provide an improved method and system for generating output test JCL files through greater efficiency in the processing of jobs and procs in JCL generation.